1. Technical Field
The present invention relates in general to the data processing field. More specifically, the present invention relates to the field of object-oriented programming techniques and mechanisms.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices. Modem computer systems contain relatively complex software that the computer hardware executes in order for the computer system to perform its intended functions. As the complexity of computer hardware and software increases, the need to efficiently and effectively develop new software becomes more acute. Software development costs have continued to rise because complex programs take more time, and hence more money, to produce. Object-oriented programming is one way computer programmers have sought to reduce the time and costs associated with developing complex software.
The goal of using object-oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and reusable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Typically, object-oriented software programs or processes create and use objects to accomplish the required or desired goals of the application software. Most software processes will create an object or group of objects and then use those objects during the lifetime of that particular process. Whenever a new object is to be created in an object-oriented environment, the new object may be created in a location specified explicitly by the system designer. Alternatively, new objects may simply be created in a default physical memory location specified by the system. While this may work reasonably well for some systems and object-oriented processes, it may occasionally lead to some notable system performance and system security problems. Certain objects have an "object affinity" with other objects. This means that in a given system, certain objects tend to be used together and with each other. Therefore, if the objects can be created in the same physical location, the overall system will typically perform better.
The location of related objects becomes an even more important issue in distributed object systems. A distributed object system is a system that has two or more objects in different locations that may communicate with each other. These objects may be in processes running on two completely separate computer systems or may be in different processes running on the same computer system. If a first object, located on a given system (e.g. computer) needs to frequently reference a second object that is located on a different system which is located in a geographically remote location, communication time between the two objects can be greatly and unnecessarily increased because there is a certain amount of communication overhead in every system-to-system communication environment.
Another problem with having objects located on disparate systems is highlighted by examining computer system security concerns. In general, different computer systems will have very different security requirements and capabilities. For example, one computer system server may store data objects in a relational data base which is carefully secured by a system administrator. In this type of system, only certain users have access to the data objects in the data base. In a second system, the server may store data objects in a file system which is accessible to all users of the system. If two separate objects are located on these different systems, it will be necessary to navigate the intricacies of multiple security systems with varying access requirements. This additional overhead will typically increase processing time and decrease system performance. If, on the other hand, all of the objects were located in the same physical memory location, only one security system must be navigated to gain access to all of the objects.
Finally, without regard to system security restrictions, access and availability of system resources can vary greatly from system to system. Some systems and system resources are unavailable for certain periods of time due to system administration procedures and requirements. This means that certain objects located on remote systems may be unavailable to another system due to system level administration requirements such as backup or recovery procedures. The more systems involved in a given processing scenario, the more likely it is that one or more of the systems may be unavailable at any given moment. This may introduce unnecessary delays into the processing model because the first object may have to wait for the second object, which is located on a different system, to become available. If, on the other hand, both objects are located on the same system, then both objects will generally be available to each other at the same time.
Almost all object-oriented software applications will perform better if the objects that are used together are stored "near" each other. It the examples described above, where object affinity exists, it would generally be preferable to create a first object "near" the second object so as to allow more efficient communication. While the desirability of storing objects with object affinity in the same location may be demonstrated, there is presently no efficient or effective way of accomplishing this goal.
As both the complexity and the frequency of communication and transaction processing over networked computer systems increases, the need for better ways of creating and managing objects in object-oriented systems becomes more apparent and more acute. This is especially true as more and more computers are connected by networks such as the World Wide Web and share information across different computer systems. Without a mechanism for creating objects in a way that further reduces operational overhead and logistical performance problems, the computer industry will never fully realize the benefits of object-oriented programming environments.